src/main/java/org/scoula/domain/precontract/service/OwnerPreContractServiceImpl.java (4)

505-510: 민감정보(PII) 로그 노출 위험: 전체 Document 로깅 제거 필요

OwnerMongoDocument 전체를 로깅하면 계좌번호 등 민감정보가 그대로 로그에 남습니다. 요약 정보(식별자 중심)만 남기도록 수정이 필요합니다.

다음과 같이 수정하세요:

-              log.info("변환된 document: {}", document);
+              // PII 노출 방지를 위해 전체 객체 대신 키 정보만 로깅
+              log.info("Mongo 저장 시작 - contractChatId: {}, userId: {}", dto.getContractChatId(), dto.getUserId());
 ...
-              log.info("Mongo 저장 결과: {}", result);
+              // 저장 완료 시에도 민감정보는 로깅하지 않음
+              log.info("Mongo 저장 완료 - contractChatId: {}, userId: {}", result.getContractChatId(), result.getUserId());

---

576-581: 민감정보(PII) 포함 가능 JSON 전체 로깅 금지

aiRequest 전체를 JSON으로 직렬화하여 로그에 남기는 것은 RRN/계좌/주소 등 다수 PII 노출 가능성이 큽니다. 요약 정보만 로깅하도록 변경해 주세요.

-              log.info("AI 요청 데이터: {}", objectMapper.writeValueAsString(aiRequest));
+              // 민감정보 노출 방지를 위해 요약만 로깅
+              log.info("AI 요청 요약 - contractChatId: {}, ownerPrecheckId: {}, specialTermsCount: {}",
+                       aiRequest.getOwnerData().getContractChatId(),
+                       aiRequest.getOwnerData().getOwnerPrecheckId(),
+                       aiRequest.getOcrData() != null && aiRequest.getOcrData().getSpecialTerms() != null
+                         ? aiRequest.getOcrData().getSpecialTerms().size()
+                         : 0);

---

427-443: NPE 위험: contractChat/chatRoom null 체크 필요

findByContractChatId 또는 findByUserAndHome가 null을 반환할 경우 NPE가 발생합니다. 명시적으로 검증하고 비즈니스 예외를 던지세요.

-          ContractChat contractChat = contractChatMapper.findByContractChatId(contractChatId);
-          ChatRoom chatRoom =
-                  chatRoomMapper.findByUserAndHome(
-                          contractChat.getOwnerId(),
-                          contractChat.getBuyerId(),
-                          contractChat.getHomeId());
+          ContractChat contractChat = contractChatMapper.findByContractChatId(contractChatId);
+          if (contractChat == null) {
+              throw new BusinessException(OwnerPreContractErrorCode.OWNER_SELECT, "계약 채팅 정보가 존재하지 않습니다.");
+          }
+
+          ChatRoom chatRoom =
+                  chatRoomMapper.findByUserAndHome(
+                          contractChat.getOwnerId(),
+                          contractChat.getBuyerId(),
+                          contractChat.getHomeId());
+          if (chatRoom == null) {
+              throw new BusinessException(OwnerPreContractErrorCode.OWNER_SELECT, "채팅방이 존재하지 않습니다.");
+          }

---

84-87: RuntimeException 대신 도메인 예외 사용

검증 실패 시 RuntimeException은 모호하며 글로벌 에러 핸들러/응답 규격과도 어울리지 않습니다. BusinessException + 전용 에러코드로 교체하세요.

-          if (!result) {
-              log.warn("신분증 진위 확인 실패");
-              throw new RuntimeException("신분증 검증 실패");
-          }
+          if (!result) {
+              log.warn("신분증 진위 확인 실패");
+              throw new BusinessException(OwnerPreContractErrorCode.OWNER_ID_VERIFICATION_FAILED, "신분증 검증 실패");
+          }

추가로 OwnerPreContractErrorCode에 전용 코드를 정의해 주세요:

// OwnerPreContractErrorCode.java
OWNER_ID_VERIFICATION_FAILED, // 신분증 진위 확인 실패

필요하시다면 관련 enum/코드 추가 PR 스캐폴딩을 제공해 드리겠습니다.

src/main/java/org/scoula/domain/chat/service/ContractChatServiceImpl.java (2)

2393-2397: [버그] 수정요청 대기여부 키 불일치로 항상 false 가능성

요청 저장은 final-contract:modification:{contractChatId}:{ownerId} 키에 JSON(clauseOrder, requestData)로 저장되는데, 조회는 {clauseOrder}를 키에 사용하고 있어 불일치합니다. 결과적으로 항상 false가 반환될 수 있습니다. 저장 포맷에 맞춰 키/값을 검증하도록 수정하세요.

다음과 같이 키를 ownerId 기준으로 정정하고, 값에서 clauseOrder를 검증하세요.

-      public boolean hasPendingModificationRequest(Long contractChatId, Integer clauseOrder) {
-          String redisKey = "final-contract:modification:" + contractChatId + ":" + clauseOrder;
-          return stringRedisTemplate.hasKey(redisKey);
-      }
+      public boolean hasPendingModificationRequest(Long contractChatId, Integer clauseOrder) {
+          ContractChat contractChat = contractChatMapper.findByContractChatId(contractChatId);
+          if (contractChat == null) return false;
+          String redisKey =
+                  "final-contract:modification:" + contractChatId + ":" + contractChat.getOwnerId();
+          String valueDataJson = stringRedisTemplate.opsForValue().get(redisKey);
+          if (valueDataJson == null) return false;
+          try {
+              com.fasterxml.jackson.databind.JsonNode rootNode = objectMapper.readTree(valueDataJson);
+              Integer storedClauseOrder = rootNode.get("clauseOrder").asInt();
+              return clauseOrder.equals(storedClauseOrder);
+          } catch (Exception e) {
+              log.warn("수정 요청 데이터 파싱 실패: {}", e.getMessage());
+              return false;
+          }
+      }

---

2700-2765: [버그] 최종 특약 삭제 수락 로직의 Redis 키/값 검증 오류

요청 저장: final-contract:deletion:{contractChatId}:{ownerId} 키에 value로 clauseOrder 저장
수락 시: 현재는 final-contract:deletion:{contractChatId}:{clauseOrder} 키를 조회하고 value를 ownerId로 간주하여 비교합니다. 키와 값 모두 불일치입니다.

다음과 같이 키를 ownerId로, 값 비교를 clauseOrder로 정정하세요.

-        String redisKey = "final-contract:deletion:" + contractChatId + ":" + clauseOrder;
-        String storedOwnerId = stringRedisTemplate.opsForValue().get(redisKey);
+        String redisKey =
+                "final-contract:deletion:" + contractChatId + ":" + contractChat.getOwnerId();
+        String storedClauseOrder = stringRedisTemplate.opsForValue().get(redisKey);

-        if (storedOwnerId == null) {
+        if (storedClauseOrder == null) {
             throw new BusinessException(
                     ChatErrorCode.CONTRACT_END_REQUEST_NOT_FOUND, "삭제 요청이 존재하지 않습니다.");
         }

-        if (!storedOwnerId.equals(contractChat.getOwnerId().toString())) {
+        if (!storedClauseOrder.equals(String.valueOf(clauseOrder))) {
             throw new BusinessException(
                     ChatErrorCode.CONTRACT_END_REQUEST_INVALID, "삭제 요청 정보가 유효하지 않습니다.");
         }

src/main/java/org/scoula/domain/precontract/service/OwnerPreContractServiceImpl.java (8)

443-446: Mongo 선저장 타이밍 변경은 합리적. 다만 중복 저장/실패 복구 전략을 확인하세요.

AI 메시징 전에 saveContractMongo를 수행하도록 한 변경은 일관성 있고 의존성 순서도 적절합니다. 다만 다음을 확인해 주세요:

• 이 메서드가 재호출되어도 중복 문서가 생기지 않도록 idempotent(예: (contractChatId, userId) 유니크 인덱스 + upsert)인지.
• 이후 메시징(handleChatMessage, AiMessage) 실패 시 DB 상태를 롤백할지, 아니면 저장 성공을 우선시하고 메시징은 재시도/보상 흐름으로 처리할지 정책.

필요 시 메시징 부분을 예외로부터 격리(try/catch)하여 DB 커밋과 분리하는 것도 고려해 주세요.

---

439-441: URL 콘텐츠가 하드코딩된 placeholder입니다

"계약 채팅방 URL"은 실제 사용자가 클릭할 수 있는 링크가 아닙니다. 프론트 베이스 URL을 환경변수/설정에서 주입받아 실제 경로로 구성해 주세요.

예시:

-                          .content("계약 채팅방 URL")
+                          // TODO: 실제 프론트 URL로 대체 필요
+                          .content(String.format("/contract-chat/%d", chatRoom.getChatRoomId()))

클래스 필드에 @Value("${app.frontend.base-url}") 등을 주입받아 절대경로로 구성할 것을 권장합니다.

---

508-508: 중복 호출 안전성: insert → save(upsert) 전환 제안

insert는 동일 문서 재저장 시 중복키 예외를 유발할 수 있습니다. save로 전환하여 upsert 동작을 허용하면 재실행/재시도에 안전합니다.

-              OwnerMongoDocument result = mongoRepository.insert(document);
+              // insert 대신 save로 upsert 동작을 허용 (중복 호출 안전)
+              OwnerMongoDocument result = mongoRepository.save(document);

---

584-598: 특약 추천 round 고정값(1L)은 중복 저장/충돌 위험

round를 1L로 고정하면 동일 계약 채팅에 대해 여러 번 호출 시 충돌하거나 덮어쓸 수 있습니다. 최신 round를 조회하여 +1 하거나, idempotency 키로 덮어쓰기를 명확히 해 주세요.

원하시면 MongoTemplate/Repository 기반으로 최신 round 조회 → next round 계산 로직을 제안드립니다.

---

433-433: 반환값 미사용 호출

contractChatService.getContractChatStatus(contractChat.getStatus())의 반환값을 사용하지 않습니다. 사이드이펙트가 없다면 제거, 있다면 의미 있는 검증 로직으로 치환해 주세요.

---

53-53: 서비스 인터페이스 네이밍이 가이드와 불일치

코딩 가이드에 따르면 서비스는 *ServiceInterface/*ServiceImpl 페어를 사용해야 합니다. 현재 구현은 implements OwnerPreContractService로 보입니다. 인터페이스를 OwnerPreContractServiceInterface로, 구현체는 해당 인터페이스를 구현하도록 리네이밍을 검토해 주세요.

---

100-108: 주민번호 앞자리/주소 평문 저장은 규제/보안 리스크

ssnFront, addr1, name을 평문으로 저장하고 있습니다. 국내 규제 상 주민번호는 일부라도 엄격한 보호가 요구될 수 있습니다. 최소한 앞자리도 암호화/토큰화하거나, 별도 키 관리/접근통제를 강제하는 스토리지로 이동하는 방안을 검토해 주세요.

보관 기간/마스킹 정책/접근 로그 요건 등 컴플라이언스 체크리스트가 필요하면 함께 정리해 드리겠습니다.

---

207-215: 복구 범위 upsert 시 삭제 동기화 누락 가능성

요청 DTO에서 빠진 카테고리를 DB에서 제거하지 않으면 이전 선택이 잔존할 수 있습니다. 현재는 upsert만 수행하므로, 요청 리스트 기준으로 DB를 동기화(미포함 항목 삭제)하는 로직 추가를 권장합니다.

src/main/java/org/scoula/global/config/ServletConfig.java (2)

100-114: CORS 설정이 비활성화됨 — 필요 시 활성화하거나 전역 Bean으로 이동 권장

현재 addCorsMappings 전체가 주석이며, Nginx에서 CORS 헤더를 관리한다는 주석도 있습니다. 운영 구성에 따라 선택지가 갈립니다:

• Spring에서 CORS까지 관리: 아래 메서드를 활성화하고 CorsRegistry import를 유지하세요.
• Nginx에서 전담: 이 블록을 제거하고 import도 삭제해 중복 설정과 포맷 실패 가능성을 줄이세요.

또한 allowCredentials(true)를 사용할 때는 와일드카드 Origin(*)을 사용할 수 없는데, 현재는 명시적 Origin 리스트라서 OK입니다.

메서드를 활성화하려면 아래 패치를 참고하세요:

-//      @Override
-//      public void addCorsMappings(CorsRegistry registry) {
-//          registry.addMapping("/**")
-//                  .allowedOrigins(
-//                          "http://localhost:5173",
-//                          "http://localhost:8080",
-//                          "https://itzeep.ariogi.kr",
-//                          "https://www.itzeep.ariogi.kr",
-//                          "http://itzeep.ariogi.kr",
-//                          "http://www.itzeep.ariogi.kr")
-//                  .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS", "PATCH")
-//                  .allowedHeaders("*")
-//                  .allowCredentials(true)
-//                  .maxAge(3600);
-//      }
+      @Override
+      public void addCorsMappings(CorsRegistry registry) {
+          registry.addMapping("/**")
+                  .allowedOrigins(
+                          "http://localhost:5173",
+                          "http://localhost:8080",
+                          "https://itzeep.ariogi.kr",
+                          "https://www.itzeep.ariogi.kr",
+                          "http://itzeep.ariogi.kr",
+                          "http://www.itzeep.ariogi.kr")
+                  .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS", "PATCH")
+                  .allowedHeaders("*")
+                  .allowCredentials(true)
+                  .maxAge(3600);
+      }

운영 환경에서 CORS를 어디서 책임질지 확정되지 않았다면 알려주세요. 선택에 맞춰 Spring 쪽 구성/코드 정리를 도와드리겠습니다.

---

17-17: 불필요한 CorsRegistry import 제거 제안

CorsRegistry가 실제 코드에서 사용되지 않고 주석 처리된 CORS 메서드만 참조하므로 import를 제거해주세요.
(추후 CORS 적용 계획이 있다면 해당 메서드를 활성화하는 방향으로 정리해 주세요)

• 파일: src/main/java/org/scoula/global/config/ServletConfig.java (17행)

적용 가능한 패치:

--- a/src/main/java/org/scoula/global/config/ServletConfig.java
+++ b/src/main/java/org/scoula/global/config/ServletConfig.java
@@ -15,7 +15,6 @@
 import org.springframework.web.multipart.support.StandardServletMultipartResolver;
-import org.springframework.web.servlet.config.annotation.CorsRegistry;
 import org.springframework.web.servlet.config.annotation.EnableWebMvc;
 import org.springframework.web.servlet.config.annotation.ResourceHandlerRegistry;

src/main/java/org/scoula/global/websocket/config/WebSocketConfig.java (4)

26-33: System.err 디버그 출력 제거 또는 logger로 교체

클래스 로딩/생성자에서 System.err.println은 운영 시 노이즈와 비용을 유발합니다. @Log4j2가 있으므로 log.debug로 대체하거나 제거해 주세요.

-      static {
-          System.err.println("🚨🚨🚨 WebSocketConfig 클래스 로딩됨!");
-      }
-
-      public WebSocketConfig() {
-          System.err.println("🚨🚨🚨 WebSocketConfig 생성자 호출됨!");
-      }
+      // 디버깅이 필요할 때만 활성화
+      // static {
+      //     log.debug("WebSocketConfig 클래스 로딩됨");
+      // }
+      // public WebSocketConfig() {
+      //     log.debug("WebSocketConfig 생성자 호출됨");
+      // }

---

49-57: STOMP 엔드포인트 Origin 설정의 외부화 권장

허용 Origin이 코드에 하드코딩되어 있어 운영 환경 추가/변경 시 재배포가 필요합니다. application.yml에 배열 형태로 외부화하거나 프로파일별 분기 구성을 권장합니다. 또한 Nginx에서 CORS 헤더를 관리하더라도 Spring의 Origin 검증은 이대로 유지가 필요합니다.

---

104-109: 인증 토큰 타입 검토(선택)

UsernamePasswordAuthenticationToken(String, Object, Collection) 생성자는 authenticated=true인 인스턴스를 만듭니다. 검증 전 상태를 명확히 하거나 권한 부여가 필요 없다면 단순 Principal 구현체를 사용하거나, 검증 후에만 인증 토큰을 생성하도록 흐름을 분리하는 것을 고려하세요.

Also applies to: 123-126

---

61-140: JwtUtil Bean 재사용 권장

프로젝트에 이미 org.scoula.global.auth.jwt.JwtUtil Bean이 존재합니다. WebSocketConfig에서 직접 Base64 디코딩·파싱 로직 대신 해당 Bean을 주입하여 토큰 유효성 검사 및 사용자 정보 추출을 일관되게 처리하세요.

• 파일: src/main/java/org/scoula/global/websocket/config/WebSocketConfig.java

• 생성자(또는 필드) 주입으로 JwtUtil jwtUtil 추가
• preSend() 내부의 직접 디코딩·파싱 로직 제거
• jwtUtil.getTokenInfo(token) 호출 후 TokenInfo.getSubject() 로 사용자 설정

이렇게 하면 유지보수성과 일관성이 개선됩니다.

src/main/java/org/scoula/domain/chat/controller/ContractChatControllerImpl.java (2)

7-7: 불필요한 Objects 임포트

Objects 클래스가 Line 437에서 한 번만 사용되고 있습니다. 기존의 equals() 메서드를 직접 사용하는 방식으로도 충분하므로, 이 임포트는 선택사항입니다.

---

304-329: WebSocket 입장 로직 개선

WebSocket 계약 채팅방 입장 메서드에 상세한 로깅이 추가되었습니다. 다만 몇 가지 개선사항이 있습니다:

1. Line 318: 에러 로그 후 조용히 리턴하는 대신, 사용자에게 에러를 알려주는 것이 좋습니다
2. Principal null 체크는 이미 Line 308에서 로깅하고 있으므로, 실제 사용 시점에서 검증이 필요할 수 있습니다

 if (userId == null || contractChatId == null) {
     log.error("필수 파라미터 누락 - userId: {}, contractChatId: {}", userId, contractChatId);
+    // 에러 메시지를 클라이언트에 전송
+    Map<String, Object> errorInfo = Map.of(
+        "error", "MISSING_PARAMETERS",
+        "message", "필수 파라미터가 누락되었습니다."
+    );
+    messagingTemplate.convertAndSendToUser(
+        principal != null ? principal.getName() : "unknown",
+        "/queue/contract/error", 
+        errorInfo
+    );
     return;
 }

src/main/java/org/scoula/domain/chat/service/ChatServiceImpl.java (1)

842-848: URL 문자열 연결 대신 UriComponentsBuilder 사용 권장 (인코딩/슬래시/쿼리 안전성 개선)

현재 문자열 더하기 방식은 누락/중복 슬래시, 쿼리 파라미터 인코딩 누락 등 엣지 케이스 위험이 있습니다. Spring의 UriComponentsBuilder로 대체하면 안전성과 가독성이 좋아집니다.

다음 변경을 제안합니다:

-          String contractChatUrl =
-                  URL
-                          + PRECONTRACTURL
-                          + (contractChatRoomId.toString())
-                          + BUYERURL
-                          + "&homeId="
-                          + (originalChatRoom.getHomeId());
+          String contractChatUrl = org.springframework.web.util.UriComponentsBuilder
+                  .fromHttpUrl(URL)
+                  .pathSegment("pre-contract", contractChatRoomId.toString(), "buyer")
+                  .queryParam("step", 1)
+                  .queryParam("homeId", originalChatRoom.getHomeId())
+                  .build()
+                  .toUriString();

추가로 필요한 import:

import org.springframework.web.util.UriComponentsBuilder;

src/main/java/org/scoula/domain/contract/repository/ContractMongoRepository.java (1)

106-122: System.out.println 제거 및 로깅 일원화

콘솔 출력 대신 로거를 사용해 주세요. 저장소 레이어에서도 운영 환경 로깅 일관성이 중요합니다.

다음과 같이 교체를 제안합니다:

-          System.out.println("특약 내용 삭제 완료 - contractChatId: " + contractChatId);
+          log.info("특약 내용 삭제 완료 - contractChatId={}", contractChatId);

클래스 상단에 로거 추가(외부 범위 변경):

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

@Repository
public class ContractMongoRepository {
    private static final Logger log = LoggerFactory.getLogger(ContractMongoRepository.class);
    ...
}

src/main/java/org/scoula/domain/contract/service/ContractFixServiceInterface.java (1)

7-7: 반환형은 Wrapper Void보단 기본형 void 사용 권장

Void는 일반적으로 의미 없는 반환을 객체로 다뤄야 할 때만 사용합니다. 여기서는 void가 더 적절하고 호출부에도 편합니다.

다음 변경을 제안합니다:

-      Void saveSpecialContract(Long contractChatId, Long userId);
+      void saveSpecialContract(Long contractChatId, Long userId);

src/main/resources/org/scoula/domain/precontract/mapper/TenantPreContractMapper.xml (1)

262-268: selectRentTypeAll resultType 대소문자 통일 요청
MyBatis 내 동일 파일의 selectRentType이 resultType="String"을 사용하고 있으므로, 일관성을 위해 selectRentTypeAll도 resultType="String"으로 변경해주세요.
인터페이스 TenantPreContractMapper에서 @Param("contractChatId")·@Param("userId") 매핑은 이미 올바르게 설정되어 있습니다.

• 변경 위치
  • 파일: src/main/resources/org/scoula/domain/precontract/mapper/TenantPreContractMapper.xml
  • 대상 코드: lines 262–268

-  <select id="selectRentTypeAll" resultType="string">
+  <select id="selectRentTypeAll" resultType="String">

src/main/java/org/scoula/domain/precontract/mapper/TenantPreContractMapper.java (1)

42-44: 메서드 목적 구분을 위한 JavaDoc 추가 및 @param 변수명 통일 권장

TenantPreContractMapper에 정의된 두 메서드(selectRentType vs selectRentTypeAll)는 호출 위치·범위가 다르므로, 혼동 방지를 위해 아래와 같이 리팩토링을 제안합니다.

• JavaDoc으로 용도 명시

  interface TenantPreContractMapper {
  -    Optional<String> selectRentType(
  -        @Param("contractChatId") Long contractChatId, @Param("userId") Long userid);
  +    /**
  +     * 사전계약(tenant/owner) 컨텍스트에서 전/월세 타입 조회.
  +     */
  +    Optional<String> selectRentType(
  +        @Param("contractChatId") Long contractChatId, @Param("userId") Long userId);
  
  -    Optional<String> selectRentTypeAll(
  -        @Param("contractChatId") Long contractChatId, @Param("userId") Long userid);
  +    /**
  +     * 계약 전체(모든 사전계약 데이터) 컨텍스트에서 전/월세 타입 조회.
  +     * ContractServiceImpl에서 단일 호출 시 사용.
  +     */
  +    Optional<String> selectRentTypeAll(
  +        @Param("contractChatId") Long contractChatId, @Param("userId") Long userId);
  }

• userid → userId 로 변수명 통일
  • 파일: src/main/java/org/scoula/domain/precontract/mapper/TenantPreContractMapper.java
  • 변경 대상 메서드: selectRentType, selectRentTypeAll

src/main/java/org/scoula/domain/contract/controller/ContractController.java (1)

122-131: 인증 주입 방식 통일 및 응답 DTO 사용 권장

현재 ContractController 인터페이스(src/main/java/org/scoula/domain/contract/controller/ContractController.java)와 구현체(ContractControllerImpl.java)에서
Authentication authentication을 사용 중이며, 타 엔드포인트들은 @AuthenticationPrincipal CustomUserDetails userDetails를 사용하고 있습니다.
컨트롤러 전반의 일관성을 위해 아래와 같이 시그니처를 변경해 주세요:

- ResponseEntity<ApiResponse<String>> requestFinalContract(
-     @PathVariable Long contractChatId, Authentication authentication);
+ ResponseEntity<ApiResponse<String>> requestFinalContract(
+     @PathVariable Long contractChatId,
+     @AuthenticationPrincipal CustomUserDetails userDetails);

- ResponseEntity<ApiResponse<Map<String, Object>>> acceptFinalContract(
-     @PathVariable Long contractChatId,
-     @RequestBody FinalContractDeletionResponseDto responseDto,
-     Authentication authentication);
+ ResponseEntity<ApiResponse<Map<String, Object>>> acceptFinalContract(
+     @PathVariable Long contractChatId,
+     @RequestBody FinalContractDeletionResponseDto responseDto,
+     @AuthenticationPrincipal CustomUserDetails userDetails);

• Map<String, Object> 대신 명시적 응답 DTO 사용 권장(가독성·타입 안전성↑)
• 필요 시 FinalContractAcceptResponseDto 초안 제공 가능합니다.

src/main/java/org/scoula/domain/contract/dto/LegalityDTO.java (1)

32-37: validationStatus는 Enum 도입 고려

validationStatus를 자유 문자열 대신 Enum으로 모델링하면 오탈자/상태 폭주를 방지할 수 있습니다. 예: PENDING, PASSED, FAILED 등.

예시:

public enum ValidationStatus {
    PENDING, PASSED, FAILED
}

@JsonProperty("validation_status")
private ValidationStatus validationStatus;

다운스트림/직렬화 포맷 영향이 있으므로 단계적 도입을 권장합니다.

src/main/java/org/scoula/domain/contract/service/ContractFixService.java (2)

72-77: assert 사용 제거 및 로그 민감도 조정 제안

• assert로 null을 강제하는 것은 프로덕션에서 비활성화되어 무의미하거나, 활성화된 경우 불필요한 AssertionError를 유발할 수 있습니다. 아래 if 블록에서 이미 null 체크를 하므로 assert는 제거하세요.
• 응답 전체를 warn 레벨로 출력하면 과도한 정보(민감정보 포함)가 로그로 남을 수 있습니다. 상태코드 중심의 debug 로그로 낮추는 것을 권장합니다.

다음과 같이 정리하는 것을 제안합니다:

-              LegalityDTO res = response.getBody();
-              assert res != null;
-              log.warn("AI 응답 값 확인: {}", res.toString());
-
-              log.warn("AI 응답 헤더 확인: {}", response.getStatusCode());
+              LegalityDTO res = response.getBody();
+              // 응답은 아래 조건문에서 null 체크합니다. assert 사용은 지양합니다.
+              log.debug("AI 응답 상태: {}", response.getStatusCode());

---

94-97: 예외 로그에 스택트레이스 포함

현재는 메시지 문자열만 로깅하여 원인 파악이 어려울 수 있습니다. 스택트레이스를 포함해 주세요.

-          } catch (Exception e) {
-              log.error(e.getMessage());
-              throw new BusinessException(ContractException.CONTRACT_AI_SERVER_ERROR, e);
-          }
+          } catch (Exception e) {
+              log.error("AI 서버 호출/파싱 실패", e);
+              throw new BusinessException(ContractException.CONTRACT_AI_SERVER_ERROR, e);
+          }

src/main/java/org/scoula/domain/contract/service/ContractServiceImpl.java (3)

234-241: 전/월세 타입 매핑의 하드코딩 최소화

문자열 비교 대신 enum 또는 상수 사용을 권장합니다. 또한 NPE를 방지하려면 equals 비교 방향을 상수 우선으로 유지하세요.

-          String rentTypeKr;
-          if(rentType.equals("JEONSE")){
+          String rentTypeKr;
+          if ("JEONSE".equals(rentType)) {
               rentTypeKr = "전세";
           }else{
               rentTypeKr="월세";
           }

추가로, 향후 타입이 늘어날 경우 switch 문이나 매핑 테이블(Map<String, String>)로 확장성을 확보하는 것이 좋습니다.

---

149-154: 서비스 레이어에서 Thread.sleep 사용 지양

블로킹 대기(2초)는 처리량과 응답성에 악영향을 줍니다. 비동기 이벤트(메시지 큐/스케줄링)나 클라이언트 측 지연 표시로 대체를 권장합니다.

Also applies to: 199-211, 375-383

---

278-288: Redis 저장 포맷 변경(CSV) 검증 완료 및 TTL 적용 권장

전역 검색 결과 contract:payment:{contractChatId} 키를 읽는 코드는 모두 ContractServiceImpl 내에 있으며, JSON을 기대하는 별도 소비자는 없습니다.
임시 합의값 특성 상 데이터 유실·방치 방지를 위해 TTL을 추가 적용할 것을 권장합니다.

• 파일: src/main/java/org/scoula/domain/contract/service/ContractServiceImpl.java
  – saveDepositPrice, updateDepositPrice, 삭제 로직 모두 CSV("deposit,monthly")로 정상 처리됨
• 권장 적용 예시:

-        stringRedisTemplate.opsForValue().set(redisKey, paymentValue);
+        stringRedisTemplate.opsForValue().set(redisKey, paymentValue, Duration.ofMinutes(30));

src/main/java/org/scoula/domain/chat/service/ContractChatServiceImpl.java (3)

2475-2624: 적법성 검사 결과 과다 로깅(PII/민감정보) 가능성

위반 세부내용(조항 원문, 개선안 등)을 info 레벨로 상세히 로그에 남기고 있습니다. 운영 환경에서는 debug 레벨로 낮추거나, 요약/マ스킹 처리로 전환하세요. 프런트 전달은 메시지 전송(AiMessage*)로 충분합니다.

---

627-638: Redis 기반 온라인 상태로 통일 권장(중복 상태 관리 제거)

contractChatOnlineUsers 인메모리 맵을 online/offline에서 부분적으로만 사용하고 있어(online 세팅은 미사용), 상태 관리가 이원화되어 혼란을 유발할 수 있습니다. Redis 기반으로 일원화하고 인메모리 경로는 제거하는 것을 권장합니다.

Also applies to: 641-652

---

497-513: Presence TTL/유실 복구 검토

입장/퇴장 시 Redis 셋을 갱신하지만, 비정상 종료(브라우저 강제 종료 등) 복구 전략이 없습니다. 주기적 하트비트/TTL 기반 만료, 또는 세션 종료 훅과의 연동을 검토하세요.

Also applies to: 519-526

src/main/java/org/scoula/domain/contract/controller/ContractControllerImpl.java (3)

214-230: 스웨거 문서화 어노테이션 추가 권장(가이드라인 준수)

컨트롤러 엔드포인트는 Swagger 문서화를 권장합니다. 최소한 신규 엔드포인트에 @Operation을 추가하세요. 클래스 레벨 @Tag도 함께 권장합니다.

+import io.swagger.v3.oas.annotations.Operation;
+import io.swagger.v3.oas.annotations.tags.Tag;
@@
-@RestController
+@RestController
+@Tag(name = "Contract", description = "계약 진행/특약/적법성 관련 API")
@@
-      @PostMapping("/specialContract/final-request")
+      @Operation(summary = "최종 특약 확정 요청", description = "임대인이 임차인에게 최종 특약 확정을 요청합니다.")
+      @PostMapping("/specialContract/final-request")
       public ResponseEntity<ApiResponse<String>> requestFinalContract(
               @PathVariable Long contractChatId, Authentication authentication) {

---

232-253: 스웨거 문서화 어노테이션 추가 권장(수락/거절 엔드포인트)

동일하게 수락/거절 엔드포인트에도 @Operation을 부여해 주세요.

-    @PostMapping("/specialContract/final-accept")
+    @Operation(summary = "최종 특약 확정 수락/거절", description = "임차인이 최종 특약 확정 요청을 수락 또는 거절합니다.")
+    @PostMapping("/specialContract/final-accept")
     public ResponseEntity<ApiResponse<Map<String, Object>>> acceptFinalContract(

---

233-239: 요청 DTO 명확성 개선 제안

final-accept 요청 바디로 FinalContractDeletionResponseDto를 재사용하고 있습니다. 의미적으로 다른 목적의 DTO를 재사용하면 혼동을 유발할 수 있으므로, FinalContractAcceptRequestDto처럼 목적에 맞는 전용 DTO를 정의하는 것을 권장합니다.

원하시면 전용 DTO와 매핑 코드 패치를 생성해 드리겠습니다.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: Whatdoyumin
PR: ITZEEP/backend#40
File: src/main/resources/org/scoula/domain/precontract/mapper/OwnerPreContractMapper.xml:188-192
Timestamp: 2025-08-04T00:51:44.587Z
Learning: In the ITZEEP backend codebase, the owner_precontract_check table uses contract_chat_id as both primary key (PK) and foreign key (FK), so selectOwnerPrecheckId correctly returns contract_chat_id for use in upsertRestoreScope operations. This is confirmed by the join pattern "LEFT JOIN owner_restore_scope ors ON opc.contract_chat_id = ors.owner_precheck_id" in the mapper files.

Learnt from: Whatdoyumin
PR: ITZEEP/backend#40
File: src/main/resources/org/scoula/domain/precontract/mapper/OwnerPreContractMapper.xml:188-192
Timestamp: 2025-08-04T00:51:44.587Z
Learning: In the ITZEEP backend codebase, the owner_precontract_check table uses contract_chat_id as both primary key (PK) and foreign key (FK), so selectOwnerPrecheckId correctly returns contract_chat_id for use in upsertRestoreScope operations.

Learnt from: CR
PR: ITZEEP/backend#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-12T03:59:30.512Z
Learning: Applies to src/main/java/org/scoula/domain/*/repository/*Repository.java : Place MongoDB repositories under `src/main/java/org/scoula/domain/*/repository/*Repository.java`

Learnt from: CR
PR: ITZEEP/backend#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-12T03:59:30.512Z
Learning: Applies to src/main/java/org/scoula/**/service/*Service{Interface,Impl}.java : Use interface-implementation pattern for services: `*ServiceInterface.java` (interface) and `*ServiceImpl.java` (implementation)

Learnt from: CR
PR: ITZEEP/backend#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-12T03:59:30.512Z
Learning: Applies to src/main/java/org/scoula/**/controller/*Controller{,Impl}.java : Use interface-implementation pattern for controllers: `*Controller.java` (interface) and `*ControllerImpl.java` (implementation)